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DETAILED ACTION 

1 . This Office Action is responsive to the Amendment filed 8/26/2008. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-1 1 and 13-14 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Wittmann et al. (AMnet: Active Multicasting Network), hereafter 
Wittmann, in view of in view of Eichert et al. (US 6393474), hereafter Eichert in view of 
Alexander et al. "Active Network Encapsulation Protocol (ANEP)", hereafter AN EP. 

Regarding claims 1 and 9-11, Wittmann discloses: 

A method for reserving resources in a packet communication network, 
preferably an IP protocol network, this network being a hybrid network 
comprising both active nodes and passive nodes, the active nodes alone being 
capable of taking into account so-called active packets, that is to say those 
containing information related to a corresponding execution environment of these 
active nodes, an active data flow being a set of active packets having to be taken 
into account by one and the same execution environment (this network is 
disclosed in Fig. 1 as well as the first paragraph of section 2.1 , and that it is an IP 
network containing IP nodes), the said method comprising the steps of: 
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a) sending on the network of a reservation packet containing a request for 
reservation of resources constituting an execution environment for an associated 
active data flow; (See Fig. 3, note the RSVP message with the QF Object inside) 

b) receiving of the said reservation packet by an active node of the 
network (Fig. 3 shows the RSVP message being received at the RSVP Daemon); 
and 

c) reservation of resources of the node according to the said request, 
(Note that in Fig. RVSP Daemon forwards the QF Object to the QF Daemon, 
which then programs the QoS Filter according to the QF object thereby reserving 
the filtering resources) 

the said method being characterized in that the said reservation packet is an 
active packet. (The RSVP packet containing the QF Object is by definition active 
as it will program the QoS filters within an active node. Packets carrying 
information intended for an active node are active packets. It is clear that the QF 
Object is information intended for an active node.) 

Note that Figure 3 is the diagram of an IP active node operable to perform 
the steps above. 

Wittmann discloses all of the limitations of claim 1 except for an indicator that 
indicates that the active packet comprises executable code or identifies a server 
from which an executable code is downloadable. 

The general concept of an active node receiving code in an active packet 
reserving policy is well known in the art as taught by Eichert. (Col. 2, line 65 
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through Col. 3 line 1 which teaches that the active packet file may contain the 
policy code executable by the active network devices.) 

The general concept of a policy reservation packet identifying a server and code 
to download and execute from the server is well known in the art as taught by 
Eichert. (Col. 2, lines 60-67, Col. 3 lines 1-3 teach that the code in the active packet 
may be stored on a distributed database and the active packet may just inform the 
device where the packet may be found.) 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the method of reserving resources of Wittmann and the general 
concept of an active node receiving code in an active packet reserving policy as 
taught by Eichert in order to decouple the policy services from the underlying node 
infrastructure. 

Wittmann and Eichert teach all the limitations of claim 1 except that the packet 
has an indicator that the packet is active (i.e. that it contains executable code). 

The general concept of a packet containing code to have an indicator of that 
state is well known in the art as taught by ANEP, which discloses a protocol which is 
used to encapsulate active information within an IP packet. 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify Wittmann and Eichert to use the ANEP in order to allow co- 
existence of different execution environments and proper demultiplexing of received 
packets. 

Regarding claim 2 as applied to claim 1, Wittmann discloses: 
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the packet is in RSVP format. (Pg. 897, Col. 2, Section 3, lines 5-6 state 
that Amnet is based on RSVP.) 

Regarding claim 3 as applied to claim 1, Wittmann discloses: 

the packet may be a PATH type of the RSVP protocol. (Page 899, Col. 1 , 
Paragraph 7: "A soft state is created and periodically refreshed by PATH or 
RESV messages. QF objects are included in these messages.) 
Regarding claim 4 as applied to claim 1, Wittmann discloses: 

the reservation packet comprises an identifier of the said active data flow. 
(Page 889, Col. 1 , "different filters serve different group members in the same 
active network node", and "User data are directed directly to the corresponding 
QoS filter" clearly imply that there is a designation of a specific flow (i.e. to a 
specific group or member) that is to receive the filtering described by the QF 
object See Figure 4 (b) How Node D provides different quality data flows to 
separate receivers. Furthermore in an RSVP PATH packet inherently (See RFC 
2205, the defintiion of RSVP for more information) includes a Sender Template 
which describes the a filter spec that is used to select the proper packets from all 
the packets sent on the network.) 

Regarding claim 5 as applied to claim 1, Wittmann discloses: 

the said reservation packet is provided for containing parameters for 
processing data contained in the said associated active data flow, this processing 
being a code executable by an active node of the network, (see Fig. 2, which 
shows the format for the parameters for processing the data in the data flow) and 
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in that, in the case of these processing parameters being present, the step b) is 
followed by: 

b 1 ) a step of loading by the said active node of the said corresponding 
executable code (See Fig. 3, the QF Daemon loads and configures the 
appropriate QoS-filters); and 

b2) a step of execution of the said code by the said active node. (The 
filters are executed upon members of the group data flow that was reserved. See 
Fig. 3) 

Regarding claim 6, Eichert teaches: 

The general concept of an active node receiving code in an active packet 
reserving policy is well known in the art as taught by Eichert. (Col. 2, line 65 
through Col. 3 line 1 which teaches that the active packet file may contain the 
policy code executable by the active network devices.) 
Regarding claim 7, Eichert teaches: 

The general concept of a policy reservation packet identifying a server and 
code to download and execute from the server is well known in the art as taught 
by Eichert. (Col. 2, lines 60-67, Col. 3 lines 1-3 teach that the code in the active 
packet may be stored on a distributed database and the active packet may just 
inform the device where the packet may be found.) 
Regarding claims 8 and 13 and as applied to claims 1 and 5, Wittmann 
discloses: 
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after the step bl), a step of: b3) sending on the network by the said node of a 
confirmation of loading of the said executable code. (This step is inherent, as in the 
RSVP protocol when a node is finished with the setup requested by a PATH or 
RESV message then the message is forwarded onto the next node on the path. In 
the case of a failure, an error message is then forwarded in the opposite direction. If 
the node is unable to load the proper filters (i.e. executable code), the RSVP request 
will fail, and the error message will be returned to the originator of the PATH 
message. If the node is successful in reserving the resources (i.e. the filters 
necessary) then the path message is forwarded to the next node, thus the 
continuance of the PATH message to be forwarded means that the request 
succeeded at the previous nodes.) 

Regarding claim 14 as applied to claim 1, Wittmann discloses: 

The reservation packet comprises: a first identifier identifying the protocol for the 
data flow, a second identifier identifying the source/destination of the data flow, and 
a third identifier identifying the resources to be reserved. (An RSVP reservation 
request includes the destination of the dataflow. Fig. 2 discloses that the QF filter 
contains a protocol (In Fig. 2(b) the C-type is used to identify the video protocol used 
in the data flow) and also the resources to be used (slices per frame, whether to use 
color or black and white, the quality filter to provide)). 



Application/Control Number: 10/675,972 Page 8 

Art Unit: 2454 

4. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Wittmann, Eichert, and Alexander as applied to claim 1 above, and further in view of 
Applicant's Admitted Prior Art. 

Wittmann, Eichert, and Alexander teach all the limitations of claim 12 except for a 
flag in the header of a packet that indicates that the packet is active or passive. 

The general concept of using a flag in the header to indicate whether a packet is 
active or passive is old and well known in the art, as taught by Applicant's Admitted 
Prior Art. (See Applicant's Specification page 1 lines 29-33) 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine Wittmann, Eichert, and Alexander with the general concept of 
using a flag in the header to indicate whether a packet is active or passive in order to 
expedite the processing of flows that do not require quality filters. 

5. Claim 15 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Wittmann, Eichert, and Alexander as applied to claim 1 above, and further in view of 
Deiss et al. (US 2005/0068952), hereafter Deiss. 

Wittmann, Eichert and Alexander disclose all the limitations of claim 1 except for 
the data flow's packets containing executable code. 

The general concept of sending executable code in data packets is well known in 
the art as taught by Deiss. (see [0016] "they may include executable code 
forming an application to be executed by e.g., a microprocessor located within or 
associated with a receiver.) 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine Wittmann, Eichert and Alexander with the general concept 
of sending executable code in data packets as taught by Deiss in order to allow 
more types of data to be transmitted on the network. 

Response to Arguments 

6. Applicant's arguments filed 8/26/2008 have been fully considered but they are 
not persuasive. 

7. Applicant argues that Wittmann fails to disclose "sending a reservation packet 
comprising a request for reservation of resources constituting an execution environment 
for the active data flow". Applicant's argument hinges upon the assumption that a 
limitation in claim 1 exists that requires the active data flow to contain executable code. 
However, specifically noting Applicant's addition of claim 15 which -requires- executable 
code, implies that a broader meaning must be given to the independent claim. These 
video streams are executed upon by the nodes in Wittmann, as the data streams are 
altered by the code executing on the nodes, which have been configured by the RSVP 
packets (i.e. the QF filters). 

8. Applicant argues that Eichart fails to disclose an active packet reserving policy. 
The Examiner points to Eichart, Col. 8, in which the 'rules' are encoded into java objects 
intended to be executed by an active node. This can also include storing references to 
variables and methods necessary to execute the objects. (See specifically lines 64-67, 
lines 42-55, and lines 8-30). 
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9. The Examiner disagrees with Applicant's characterization of Alexander, And will 
clarify his position here. The 'indicator' is not a specific portion of the header as 
Applicant is attempting to find, but instead the entire header itself is an indicator that the 
packet is active. (I.e. the header found on page 2). 

1 0. Finally, Applicant argues that Wittmann does not disclose that the packet is a 
PATH type packet. 

1 1 . The Examiner will refer Applicant to the RSVP v1 Functional Specification (RFC 
2205) which was entered into the record by the Applicant in the IDS dated 10/2/2003. 
Note page 19, which shows an exemplary way in which RSVP works, and a short 
description of PATH and RESV messages. Further information can be found within the 
document as far as the nature of the PATH and RESV messages. Essentially, the 
sender of data sends a PATH message to the receiver. This message is used to find if 
there is a path that will support the requirements of the data flow between them. Once 
the receiver gets the PATH message, it response with an RESV message, which 
actually confirms the reservation of resources upon the data path. 

12. Applicant admits that Wittmann discloses using the RVSP protocol. Wittmann 
discloses that QF filters are in both the PATH and RESV messages (as would be 
necessary in order to actually reserve the QF filters desired). 

1 3. The Examiner believes that a telephonic interview may expedite the prosecution 
of this case. 
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Conclusion 

14. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to MICHAEL E. KEEFER whose telephone number is 
(571)270-1591 . The examiner can normally be reached on Monday through Friday 
9am-5pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan Flynn can be reached on (571) 272-1915. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

12/2/2008 MEK 

/Dustin Nguyen/ 

Primary Examiner, Art Unit 2454 



